查看原文
其他

对Layer2而言,强制提款与逃生舱功能到底有多重要?

Faust 极客 Web3 2024-01-20

作者:Faust,极客Web3


在现实世界中,几乎每一栋高楼大厦都有一个不可或缺的要素:安全出口。当火灾地震等突发事件降临时,安全出口就是保障人们生命安全的救命稻草。而在以太坊Layer2这个承载了百亿美元资产的托管平台体系中,可以让用户把资产安全撤回至Layer1的“强制提款”功能已然成为不可或缺的必备设施。


Vitalik在最近的文章“Different types of layer 2s”中也强调,用户能否顺利的把资产从Layer2撤回至Layer1,是一个非常重要的安全指标。



但“顺利提款”问题在过去似乎没有得到大多数人的重视,甚至许多Layer2项目方都没有上线“强制提款”或“逃生舱”功能。在L2生态体系未成火候的时代,漠视“无需许可的提款”似乎不成问题。但如今Layer2已经承载了120多亿美元的资产,已然变成了一栋“太大而不能倒”的大厦。如果这样的一栋摩天大楼没有安全出口,后果简直是不可想象的。

抱着让广大读者重视Layer2安全风险的目的,《极客web3》将在下文以路印协议V3和Arbitrum为例,为大家阐明为何forced withdraw与escape hatch等“无需许可的提款功能”是Layer2不可缺少的一环

(根据L2BEAT dYdX浏览器显示,迄今为止dYdX强制交易/提款功能,总计被使用过152次,超过100万美元的大额提款多达7笔)
抗审查性是大问题:如果Sequencer故意拒绝你的请求,怎么办

过去关于Layer2的科普文章往往有一个问题,就是大多数时候都着重强调“安全性”与表面上的“可用性”,却忽略了“抗审查性”。即便是在谈论去中心化排序器方案时,很多人注意到的也是MEV是否去中心化,而不是抗审查性的改善。

换句话说,大多数人往往注重Layer2的状态转换是否有效,排序器能不能盗币,欺诈证明/有效性证明系统有没有投入使用,却忽略了一个不该被忽视的风险:如果Sequencer一直拒绝你的交易请求,或者干脆长时间故障,甚至停机,这个时候怎么办?

要知道,在Solana宕机期间,曾有人因为资产面临清算而无法及时补仓,使得几百万美元的资产面临风险。此类拒绝用户请求的场景一旦发生,造成的经济损失并不可小视。


即便只有个别人可能遭遇此类情况,但如果落到了一些手握大量资金的鲸鱼身上,整个市场都可能连带遭殃(假设某人在以太坊上的Defi借贷协议有几亿美元资产可能在一周内被清算,但他因为用了Tornado而被OFAC列入制裁名单。此人大部分资金都在OP上,而OP排序器配合OFAC拒绝它的请求)

我们不妨把这个问题投射到avalanche或polygon等独立于以太坊的公链上去分析。如果Avalanche上超过2/3的Validator共识节点决定对你展开交易审查,那么它们可以拒绝把你发起的Txn打包进区块里,或者不承认包含你的Txn的区块。这个时候,你的钱基本就被埋在了这条链里出不来:

除非你能拉拢一些Validator,使得参与审查攻击的Validator不足2/3,或者你能号召一些人通过社会共识的方法,把Avalanche分叉。显然在这个时候,你还是有办法把资金快速撤出Avalanche的,并且我们要考虑到,超过2/3的Validator联合起来对某个地址发起交易审查,本身就需要一段时间去达成,这会给被审查的用户留下充沛时间“逃出生天”。

但在Layer2上,这种情况可能大不相同。Layer2的Sequencer一般都是由官方自己在运行,如果Sequencer想要对你展开审查攻击,它可以把你的钱“冻结在Layer2”,也就是彻底拒绝你发起的,把资产从L2跨到L1的交易请求。显然按照L2的运作机理,如果你不能绕开排序器执行提款操作,是完全可能被Sequencer把资产冻结在L2不能转移走的。
 

那么该怎么解决这种问题呢?其实说白了就是,怎么实现“无需许可”的提款功能,让用户在被Sequencer或Layer2项目方审查的情况下,安然无恙的把资产撤回到Layer1上?有一些项目方提出了去中心化Sequencer的方案,但这治标不治本,如果这些数量极为有限的排序器联合起来审查你,还是可以把你的资产“冻结”,况且POS节点的反女巫也是个棘手的问题(参考Multichain事件)。

真正最有效的办法,是直接在L1链上设置一个“出口”,让用户在长时间得不到Sequencer响应时,通过L1上的专用出口把资金从L2撤出。


路印协议V3版本的强制提款与破产清算模式

这里我们以路印协议的V3版本为例,它针对用户发起的强制提款分列了两种不同情况,第一种情况是:

用户直接在Layer1上通过ExchangeV3合约中的forcedWithdraw函数发起强制提款,声明自己在路印协议的L2账户是哪个,以及要提走哪种Token。之后,ExchangeV3合约会抛出一个链上事件,提示有人发起了强制提款请求。由于路印协议的所有节点(包括Sequencer)都运行着Geth客户端,所以会从以太坊区块中获知,有人发起强制提款并触发了对应的链上事件。
 

要注意的是,强制提款不会被立刻处理,而是置入pendingForcedWithdrawals队列,处于待处理状态。Sequencer注意到有人在Layer1发起强制提款后,一般会在15天内触发ExchangeV3合约中的Process函数,在以太坊链上把Token转给提款发起者(从L2项目方在以太坊链上的存款地址,给提款者转钱)。 

如果Sequencer在15天内没有响应用户的强制提款请求,用户可以调用notifyForcedRequestTooOld函数,让ExchangeV3合约抛出名为WithdrawalModeActivated的事件,通知路印协议的全节点,破产清算模式被激活了。
 

如果破产清算模式被激活,此时路印协议V3会停止接收Sequencer提交的新L2区块,也就是说这个时候路印协议整个就停止了运转。这个过程会持续至少30天。


但在破产清算模式下,用户依然可以在Layer1上把自己的资产提走,只不过需要提交merkle proof证明自己的资产状况/状态,在L2的状态树上是可查的。(证明自己在Layer2的资产余额,和自己发起提款时声明的金额是一致的


路印协议的这种破产清算模式,在L2BEAT上也被称作Escape Hatch逃生舱机制。这种模式的触发有个先决条件,就是排序器在规定的时间内没有响应用户的强制提款请求,或者Sequencer长期故障或停机。此时用户可以通过手动触发的方式,让Rollup合约进入冻结模式/停止运转。然后用户可以构造merkle Proof证明自己在Layer2上的资产情况,从L2项目方在L1的存款地址中,把属于自己的那部分资产提走。


在StarkEx的文档中,还为这一过程画了专门的示意图。如果L2用户在L1提交的Forced Withdrawal请求在7天窗口期结束时,未得到定序器响应,则该用户可以调用freeze Request功能让L2进入冻结期。此时,L2定序器将无法在L1上更新L2的状态,L2状态冻结后要过1年才能解冻。之后用户可以提交merkle proof并提款。


但要构造Merkle Proof,需要先获知完整的L2状态树,也就是需要找一个L2全节点索要数据,同时需要一段代码来生成merkle Proof,显然这需要一定的技术门槛。为了方便广大用户,L2BEAT此前曾声明,Layer2应该设置一批权限开放且代码开源的全节点,帮用户获知L2上全体账户的状态(包含余额、交易次数等)。这一举动其实也说明了强制提款与逃生舱机制的重要性。
 

Arbitrum的“强制包含交易”功能

但强制提款/逃生舱似乎不是唯一的抗审查解决方案。比如,Arbitrum采用了“强制包含交易”的方式,用户可以先在L1上的delayed Inbox合约提交需要被Sequencer处理的Txn/withdraw,如果Sequencer超过24小时没有处理,用户可以调用L1上Sequencer Inbox合约的force Inclusion函数,让Txn直接被包含进Arbitrum的交易序列中(抛出一个链上event告知Arbitrum全节点,几笔delayed Inbox上有记录的Txn需要被包含进L2的账本中)。


相比之下,Arbitrum的方法要更简单些,但这种方法还是略带不足:因为它只抛出一个链上事件告诉Arbitrum节点,有几笔被排序器忽略了的交易需要被包含进L2最长链中,而不是像路印协议和StarkEx的 破产模式/逃生舱 那样允许用户直接在L1上把钱提走。如果Arbitrum的挑战者节点联合起来发动审查攻击,似乎还是可以让用户的钱被冻结在L2。

所以说Arbitrum的force Inclusion还不够permissionless,虽然只要有一个诚实节点愿意发布欺诈证明,就可以指出排序器忽略了某个用户的forceInclusion请求,但这还是引入了一定程度的信任假设,只不过程度很轻微。

更确切的说,“需要被强制包含的交易”是要被至少1个ARB的挑战者节点认可的,这些节点目前有9个,它们有权决定给哪些L2-L1之间的跨链消息放行,现在也只有它们能发布欺诈证明。只要这9个节点联合串谋,理论上还是可以让用户的“强制交易”无效。

所以,目前Arbitrum的强制包含交易/提款,不像路印和StarkEx的破产清算模式那样无需L2节点许可。但L2BEAT还是对Arbitrum的这个方案给予了很高的评价。因为在未来,Arbitrum会上线名为BOLD的Permissionless的欺诈证明发布机制,挑战者节点届时将难以或无法串谋(现在其实就很难串谋)。


按照L2BEAT的数据,目前TVL超过5000万美元,且没有针对Sequencer Failure或Proposer Failure中的某项提供应对举措的,包括:OP Mainnet、Base、zkSync Era、Mantle、Starknet、Linea、Polygon zkEVM、Metis。这些L2都可以在极端情况下导致用户资产被冻结在L2提不出来。

所以显而易见,强制提款或破产清算模式有其存在的必要性,虽然目前它只是依靠用户-排序器这个对手方之间的博弈来发挥作用,还称不上真正意义的“随时可提款”(Arbitrum有24小时延时且可能失败,路印最长15天延时,StarkEx有7天最大延时),但显然“有总比没有好”。而且强制提款的延时问题,相信可以在未来靠着更精巧的机制设计被妥善解决(目前主要顾及到某些MEV科学家可能利用forceInclusion发起抢跑交易,所以要引入延时。具体详情可以阅读各大L2项目方的官方资料)

随着去中心化Sequencer被越来越多L2纳入路线图,以及Vitalik为首的以太坊基金会不断向人们加强对Layer2安全性的教育,类似强制提款的抗审查交易功能势必会被越来越多人所重视,这将使得以太坊Layer2体系更接近一个抗审查、去信任化的金融基础设施体系。如果Layer2实现了去信任化的资金进入进出方式,相信将会有更多做市商与流动性提供者进入L2基础设施,为整个web3的mass adoption向前推进一步。
继续滑动看下一个

对Layer2而言,强制提款与逃生舱功能到底有多重要?

Faust 极客 Web3
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存